The present invention relates generally to the development and deployment of software services in a computer-based system having a service-oriented architecture. In particular, the present invention relates to an apparatus, method, and computer program product for managing software component versions in a computer-based system having a service-oriented architecture.
In the realm of computer software systems, a service-oriented architecture (SOA) is an architectural style for creating and using business processes that are implemented with code modules typically packaged as services. Each service in a service-oriented architecture is implemented as a code module, function, object, or widget (collectively referred to herein as a software component) that is separately usable or deployable to perform a predefined task or function. An application or business process may be implemented by combining the various services of several software components. One of the fundamental principles of a service-oriented architecture is that the various services be loosely coupled, such that the services maintain a relationship that minimizes dependencies and only requires that the services maintain an awareness of one another. Accordingly, the implementation details of one service are essentially irrelevant to another service, so long as the services can communicate with one another.
In general, the services in a service-oriented architecture communicate with one another by passing data in the form of messages. Having awareness of a service means that one service “understands” the required format and data content to be included in a message sent to another service in order for that message to be properly received and processed by the other service. Accordingly, each service typically has one or more interfaces, which determine the number and nature (e.g., attributes such as data types and lengths) of the inputs expected in a service request message directed to the service. If one service—for instance, a service consumer—has knowledge of the interface of another service—for instance, a service provider—then the service consumer can direct a proper service request message to the service provider. However, problems often arise when a service is modified, such that the new version of the service has a different interface and expects different inputs (or, provides different outputs) than the previous version. In such a case, a service consumer may direct a service request message conforming to an interface of the service provider's former version, resulting in an error. Consequently, a version change to one software component (e.g., a service provider) might render several software components (e.g., service consumers) incompatible and therefore obsolete.
One solution to this problem is to utilize a middleware component, as illustrated in FIG. 1. FIG. 1 illustrates an example of a web service implemented in a service-oriented architectural environment, having a service consumer 10 communicatively connected over a network 12 with a service provider 14. As illustrated in FIG. 1, the service provider 14 includes an interface 16 and processing logic 18. From the perspective of the service consumer 10, the particular implementation of the processing logic 18 of the service provider 14 is irrelevant. However, in order for the service consumer 10 to communicate with and utilize the services of the service provider 14, the service consumer 10 must be able to generate a service request message that conforms to the specification of the interface 16 of the service provider 14. To ensure that a modification to the interface of the service provider 14 does not negatively impact the service consumer 10, the service consumer directs all service request messages to the middleware component 20. The middleware component 20, in turn, includes message conversion logic 22 to convert the service request message, if necessary, to ensure the service request message satisfies the expected inputs of the interface 16 of the service provider 14.
Unfortunately, such a solution adds to the overall complexity of the system by requiring the service consumer 10 to communicate indirectly with the service provider 14 through the middleware component 20, instead of directly with the service provider 14. Moreover, if a new version of the service provider 14 results in a changed interface 16, the conversion logic 22 of the middleware component 20 must be updated accordingly before the service consumer 10 can communicate with the service provider 14. If the new version of the service provider 14 and the new version of the middleware component 20 are not deployed simultaneously, a service consumer 10 is likely to encounter an error in communicating with the new version of the service provider 14. Furthermore, it is often the case that a developer or administrator responsible for the service provider 14 will have little if any technical knowledge about the middleware component 20, and the message conversion logic 22 in particular. Moreover, the developer or administrator responsible for the service provider 14 may not have access to the host system on which the middleware component 20 resides and executes. Hence, the overall amount of resources (e.g., developers or administrators, and time) required for making the necessary changes increases. Thus, there is a need for improving software component version management.